通信ネットワークにおけるメッセージの処理

专利摘要:
通信ネットワークにおいてセッション開始プロトコル・メッセージを処理するための方法及び装置。ネットワークノードが、Ｒｅｑｕｅｓｔ−ＵＲＩヘッダを有するセッション開始プロトコル・メッセージを受信する際に、このノードはＳＩＰメッセージ内のＲｅｑｕｅｓｔ−ＵＲＩヘッダを書き換え、メッセージの現在の宛先アドレスを決定するためにリモートノードが使用可能な情報をＳＩＰメッセージに追加する。そして、ＳＩＰメッセージは更なるノードへ送信される。このようにして、メッセージを受信するリモートノードは、例えば変換又は経路再指定の動作の結果としてＲｅｑｕｅｓｔ−ＵＲＩ内の宛先が書き換えられた場合であったとしても、ＳＩＰメッセージ内の現在の宛先を判断することができる。
公开号:JP2011509613A
申请号:JP2010541715
申请日:2008-01-10
公开日:2011-03-24
发明作者:エルバーグ，；ヨハネス ヴァン；ハンス−クリステル ホルムベリ，
申请人:テレフオンアクチーボラゲット エル エム エリクソン（パブル）；
IPC主号:H04L29-08

专利说明:

[0001] 本発明は、通信ネットワークにおけるセッション開始プロトコル・メッセージの処理に関する。]
背景技術

[0002] ＩＰマルチメディア・サブシステム（ＩＭＳ）は、移動体通信ネットワークを介してＩＰマルチメディア・サービスを提供するために第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって規定された技術である（３ＧＰＰ ＴＳ ２２．２２８）。ＩＭＳは、サービスの統合及び相互作用を通じてエンドユーザの個人対個人の通信エクスペリエンスを豊かにする鍵となる特徴を提供する。ＩＭＳによって、ＩＰベースのネットワークを介した個人対コンテンツ（クライアント対サーバ）の通信のみならず、新しい豊かな個人対個人（クライアント対クライアント）の通信が可能になる。]
[0003] ＩＭＳは、ユーザ端末（ＵＥ）間又はＵＥとアプリケーションサーバ（ＡＳ）との間の呼又はセッションをセットアップして制御するために、セッション開始プロトコル（ＳＩＰ）を使用する。ＳＩＰはＲＦＣ３２６１に記述されている。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）が、セッションのメディアコンポーネントを記述して交渉するために使用される。ＳＩＰはユーザ対ユーザのプロトコルとして作成されたが、ＩＭＳによれば、オペレータ及びサービスプロバイダがサービスに対するユーザのアクセスを制御し、それに応じてユーザに課金することが可能になる。]
[0004] ＩＭＳネットワークにおいて、呼セッション制御機能（ＣＳＣＦ）は、ＩＭＳ内のＳＩＰエンティティとして動作する。３ＧＰＰアーキテクチャは、３種類のＣＳＣＦを定義する。即ち、ＳＩＰ端末にとってのＩＭＳ内での最初の接点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入（サブスクライブ）しているサービスをユーザに対して提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び、正しいＳ−ＣＳＣＦを特定してＳＩＰ端末からＰ−ＣＳＣＦ経由で受信した要求をそのＳ−ＣＳＣＦに対して転送することを役割とするインテロゲーティングＣＳＣＦ（Ｉ−ＣＳＣＦ）である。]
[0005] ＩＭＳサービス機能は、アプリケーションサーバ（ＡＳ）を使用して実装される。いかなる所与のＵＥに関しても、１以上のＡＳをその端末に関連付けることができる。ＡＳは、ＩＭＳサービス制御（ＩＳＣ）インタフェース経由でＳ−ＣＳＣＦと通信し、要求に応じて（例えば、所与のＵＥのためにＳ−ＣＳＣＦへダウンロードされたＩＦＣの発動の結果として）ＳＩＰメッセージング経路へとリンクされる。]
[0006] ユーザは、規定されたＳＩＰＲＥＧＩＳＴＥＲメソッドを使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザＩＤに到達可能なアドレスをＩＭＳに告知するための、メカニズムである。３ＧＰＰでは、ＳＩＰ端末が登録を実行する場合、ＩＭＳはホーム加入者サーバ（ＨＳＳ）に格納された加入情報を使用してユーザを認証し、利用可能なＳ−ＣＳＣＦのセットからＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦを割り当てるための基準は３ＧＰＰでは規定されていないが、基準には、負荷分散及びサービス要件が含まれ得る。なお、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳベースのサービスに対するユーザのアクセスを制御してそれに課金することに対する、鍵となるものである。オペレータは、阻止しない場合はＳ−ＣＳＣＦをバイパスしてしまうであろうユーザ対ユーザ直接のＳＩＰセッションを阻止するメカニズムを提供することができる。]
[0007] ユーザに対して送受信される更なるシグナリングも、ＳＩＰシグナリングを使用して制御される。シグナリングの２つのエンドポイント間の各ＳＩＰクライアントは、シグナリングをルーティングして要求をルーティングすべき次のホップを発見するために、ドメイン・ネーム・システム（ＤＮＳ）を使用する。ＳＩＰは、ホップ間で要求をルーティングするためのいくつかのメカニズムを使用する。使用される主要なメカニズムのうちの１つは、ＳＩＰメッセージのヘッダ内のＲｅｑｕｅｓｔ−ＵＲＩを、要求のルーティング先となる次のホップに書き換えることである。このことは、ヘッダ内の元の宛先（ターゲット）ＩＤが中間ホップのアドレスによって置き換えられることを引き起こすであろう。元の宛先アドレスは失われ、このことは、受信者を宛先指定するために使用されていた宛先アドレスに関する知識を受信者が必要とするシナリオにおいて問題を引き起こし得る。]
[0008] 例えば、単一のユーザエージェント（ＵＡ）が自分に関連付けられた複数のアドレスを持つ場合、単一のアドレスが登録され、ＵＡは関連付けられたアドレスのうちのいずれかに対して送信された着信シグナリングを受け付けるであろう。呼の発信者によってどのアドレスが使用されたかに応じてＵＥは異なる着信音を演奏することができるため、ＵＥが例えば呼を受信する際に、どのアドレスが使用されているかをＵＥが知ることが望ましい。しかしながら、Ｒｅｑｕｅｓｔ−ＵＲＩが書き換えられている場合、ＵＡは、発呼のためにどのアドレスが使用されたかを知ることはないであろう。]
[0009] 問題が発生する他の例は、ボイス・オーバー・ＩＰ（ＶｏＩＰ）を使用して緊急サービスに対して発呼する場合である。緊急に関するＳＩＰＩＮＶＩＴＥ要求は、それが優先的な取り扱いを受けられるように、それが緊急呼であるということを示すようにマークされていなければならない。マーキングは、宛先が緊急サービス呼の受信者としての宛先（ターゲット）であるということを示すために、要求の宛先アドレス自体に対して行われる。Ｒｅｑｕｅｓｔ−ＵＲＩはＳＯＳＵＲＮを含み、要求は緊急サービスの宛先（ターゲット）に向かってルーティングされるのでＳＯＳ ＵＲＮはＲｅｑｕｅｓｔ−ＵＲＩの中に残されなければならない。しかしながら、いずれかの中間ノードがＲｅｑｕｅｓｔ−ＵＲＩを書き換える場合、ＳＯＳ ＵＲＮは失われる。]
[0010] 要求を書き換えることが問題を引き起こす更なるシナリオ例を、インターネットドラフトＩＥＴＦ draft-rosenberg-sip-ua-loose-route-01の中に見ることができる。Ｒｅｑｕｅｓｔ−ＵＲＩの書き換えが発生する事例は次の通りである。
●宛先再指定（Ｒｅｔａｒｇｅｔ）： この場合、Ｒｅｑｕｅｓｔ ＵＲＩは新しい宛先アドレスを含むので、最終宛先（エンドターゲット）はもはや元の最終宛先ではない。
●経路再指定（Ｒｅｒｏｕｔｅ）： この場合、宛先アドレスは同一のままであるが、同一のユーザに到達する他の又は中間の経路が選択されるので、Ｒｅｑｕｅｓｔ−ＵＲＩはルーティングアドレスを含むように書き換えられる。
●変換（Ｔｒａｎｓｌａｔｉｏｎ）： この場合、名前（ＵＲＮ）がアドレスに変換される。]
[0011] 上述の問題は、ルーズルーティングと共にＲｏｕｔｅヘッダを使用することにより、部分的に対処されてきた(http://tools.ietf.org/html/rfc3261)。ルーズルーティングによれば、Ｒｅｑｕｅｓｔ−ＵＲＩは上書きされないので、宛先ＵＡのＵＲＩを常に含むことになる。ＳＩＰ要求は最上位のＲｏｕｔｅヘッダフィールド内のＵＲＩへと送信されるので、Ｒｅｑｕｅｓｔ−ＵＲＩは、要求の送信先である次のホップのＵＲＩを常に含むわけではない。事実上、要求の宛先（ターゲット）と次のルーティングの宛先とが、ＳＩＰ要求のヘッダにおいて分離して保持される。]
[0012] 問題の別の部分は、登録されたユーザのコンタクトアドレスによって置き換えられたＲｅｑｕｅｓｔ−ＵＲＩの値をＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダが保持する場所である、ホームプロキシからＵＡに至る最後のホップにおいて、解決されてきた（http://tools.ietf.org/html/rfc3455を参照のこと）。]
[0013] インターネットドラフト(http://tools.ietf.org/html/draft-rosenberg-sip-ua-loose-route-01)は、ルーズルーティングのコンセプトをＵＥに拡張することにより、ルーティングメカニズムを拡張することを提案する。しかしながら、これには、対処を必要とするいくつかの問題が存在する。ルーズルーティングを単純にＵＥに拡張することは、次の物理ホップがルーズルーティングをサポートしているというのでもなければ、機能しないであろう。パス内の各エンティティはそれゆえ、次のホップエンティティがルーズルーティングをサポートしているということを知らなければならない。シグナリングパスの以前のエンティティがルーズルーティングのメカニズムを使用しており、次のホップがそれをサポートしていないということにエンティティが気付いた場合、そのエンティティは、次のホップがメッセージを正しく処理してルーティングできるようにするために、正しい値をＲ−ＵＲＩに戻すことによってメッセージを「修理」しなければならない。]
[0014] 更に、メッセージパス内の（サービスそれ自体には無関係な）エンティティがメカニズムをサポートする場合にのみ機能する「以前の」Ｒ−ＵＲＩについて受信側エンティティが知っていることに依存するサービスも存在し、このことは、そのようなサービスの使用を極めて限定的で予測不能なようにする。]
[0015] ＵＥに対するルーズルーティング・メカニズムの適用がＳＩＰルーティングを失敗させるシナリオ例には、以下のものが含まれる。]
[0016] １．（ＩＭＳネットワーク内の呼セッション制御機能のような）ルーズルーティング・メカニズムをサポートしない中間ＳＩＰプロキシ。そのようなＳＩＰプロキシは、プロキシを表す１つのエントリを伴うＲｏｕｔｅヘッダを受信し、Ｒｏｕｔｅエントリを除去するであろう。そしてプロキシは、ＲＦＣ３２６３の手順を用いてＲｅｑｕｅｓｔ ＵＲＩに基づいてメッセージをルーティングしようと試み、宛先ＩＤを変換すると得られる最初のプロキシを発見するであろう。このことは、宛先を通常に変換して得られる最初のプロキシへのループバックという結果をもたらすであろう。]
[0017] ２．メカニズムをサポートしないホームＳＩＰプロキシ。この場合、ホームＳＩＰプロキシは、ホームＳＩＰプロキシを表す１つのエントリを伴うＲｏｕｔｅヘッダを受信し、Ｒｏｕｔｅエントリを除去するであろう。そしてホームプロキシは、Ｒｅｑｕｅｓｔ ＵＲＩを分析して、これが登録されたＡｄｄｒｅｓｓ ｏｆ Ｒｅｃｏｒｄ（ＡｏＲ）であるかどうか見るであろう。もちろん、これはＡｏＲではないので、ホームＳＩＰプロキシは、ＲＦＣ３２６３の手順を用いてＲｅｑｕｅｓｔ ＵＲＩに基づいてメッセージをルーティングしようと試みるであろう。ホームＳＩＰプロキシは宛先ＩＤを変換すると得られる最初のプロキシを発見し、このことは、宛先を通常に変換して得られる最初のプロキシへのループバックという結果をもたらすであろうから、結果的にルーティングは失敗するであろう。]
[0018] ３．ルーズルーティング・メカニズムを使用してルーティングされた要求を受信するメディアゲートウェイ制御機能（ＭＧＣＦ）がＲｅｑｕｅｓｔ ＵＲＩの中にユニフォーム・リソース・ネーム（ＵＲＮ）を発見する場合がある。ＭＧＣＦはＵＲＮと連携することができないので、呼のセットアップは失敗する。]
発明が解決しようとする課題

[0019] 発明者らは、ルーズルーティング・メカニズムを拡張することに関連する問題を認識し、これに対処する方法及び装置を発明した。]
課題を解決するための手段

[0020] 本発明の第１の態様によれば、通信ネットワークにおいてセッション開始プロトコル・メッセージを処理する方法が提供される。ネットワークノードは、Ｒｅｑｕｅｓｔ−ＵＲＩヘッダを有するセッション開始プロトコル（ＳＩＰ）メッセージを受信する。このノードは、ＳＩＰメッセージ内のＲｅｑｕｅｓｔ−ＵＲＩヘッダを書き換え、メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な情報をＳＩＰメッセージに追加する。そして、ＳＩＰメッセージは更なるノードへ送信される。このようにして、メッセージを受信する何らかのリモートノードは、変換又は経路再指定の動作の結果としてＲｅｑｕｅｓｔ−ＵＲＩ内の宛先が書き換えられていた場合であったとしても、ＳＩＰメッセージ内の現在の宛先を判断することができる。この情報には、例えば、現在の宛先のＩＤを特定する情報、又は、宛先再指定の動作の結果としてＲｅｑｕｅｓｔ−ＵＲＩが書き換えられた場所を特定する情報が含まれ得る。現在の宛先アドレスは、オプションとして、メッセージの元の宛先アドレスであってもよいし、或いは、宛先再指定が原因でＲｅｑｕｅｓｔ−ＵＲＩが書き換えられた場合は、現在の宛先アドレスは宛先再指定の動作によって書き換えられたものとしてのアドレスである。]
[0021] オプションとして、メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な情報は、現在の宛先のＩＤを含む新しいメッセージヘッダを含む。これは本明細書において「Ｔａｒｇｅｔ」ヘッダと呼ばれる。代替の実施形態では、メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な情報は、メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のエントリに関連付けられるタグを含む。このタグは、エントリが宛先再指定の動作から生じたものであるということを示す。この場合、ノードはオプションとして、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内に入れられた以前の宛先アドレスに関連付けられた既存のタグを除去し、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内に入れられた現在の宛先アドレスにタグを関連付ける。このことは、ＳＩＰメッセージのサイズを削減する。]
[0022] 本発明の第２の態様によれば、通信ノードにおいて使用するための中間ノードが提供される。この中間ノードは、ＩＭＳ呼セッション制御機能のようなＳＩＰプロキシであってもよく、セッション開始プロトコル・メッセージを受信する受信機を備える。ＳＩＰメッセージ内のＲｅｑｕｅｓｔ−ＵＲＩヘッダを書き換え、メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な情報をＳＩＰメッセージに追加する、プロセッサが提供される。この中間ノードは更に、ＳＩＰメッセージを更なるノードへ送信する送信機を備える。この情報を提供することにより、変換又は経路再指定の動作の結果としてＲｅｑｕｅｓｔ−ＵＲＩ内の宛先が書き換えられた場合であったとしても、リモートノードは現在の宛先アドレスを判断することができる。]
[0023] このプロセッサはオプションとして、現在の宛先のＩＤを含む新しいメッセージヘッダをＳＩＰメッセージに挿入するように構成される。或いは、このプロセッサはオプションとして、メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のアドレスエントリにタグを追加するように構成され、このタグは、このエントリが宛先再指定の動作から生じたものであるということを示す。更なる代替では、このプロセッサは、メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のアドレスエントリにタグを追加するように構成され、このタグは、このエントリがメッセージの宛先アドレスを含むということを示す。]
[0024] 本発明の第３の態様によれば、通信ノードにおいて使用するためのノードであって、ＳＩＰメッセージを受信する受信機と、このノードと発信元ノードとの間の中間ノードによってメッセージに追加された情報に基づいて、メッセージの現在の宛先アドレスを判断するプロセッサと、を備えるノードが提供される。このノードはそれゆえ、中間ノードによる変換又は経路再指定の動作の結果としてＲｅｑｕｅｓｔ−ＵＲＩ内の宛先が書き換えられた場合であったとしても、ＳＩＰメッセージの現在の宛先アドレスを判断することができる。このノードは、ユーザ装置などの着信側ノードであってもよいし、アプリケーションサーバなどの中間ノードであってもよい。]
[0025] オプションとして、このプロセッサは、メッセージをこのノードへ送信する前に中間ノードによってメッセージ内に挿入されたＴａｒｇｅｔヘッダの内容を判断することにより、メッセージの現在の宛先アドレスを判断するように構成される。代替のオプションでは、このプロセッサは、メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のタグ付けされたエントリを分析することにより、メッセージの現在の宛先アドレスを判断するように構成される。]
図面の簡単な説明

[0026] 本発明の実施形態に関する基本的なステップを示すフロー図である。
本発明の実施形態に従うシグナリング例を示すシグナリング図である。
本発明の実施形態に従うＳＩＰシグナリングパス内の中間ノードをブロック図において概略的に示す図である。
本発明の実施形態に従う着信側ノードをブロック図において概略的に示す図である。]
実施例

[0027] 上述した問題を克服するために、ＳＩＰメッセージが、Ｒｅｑｕｅｓｔ−ＵＲＩから分離した情報要素内に元の宛先情報を保持することを提案する。これを達成可能なやり方には、新しいＳＩＰヘッダを導入すること、及び、既存のＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダの用途を拡張することが含まれる。]
[0028] 新しいＴａｒｇｅｔＳＩＰヘッダ
ＳＩＰエンティティによってＲｅｑｕｅｓｔ−ＵＲＩが書き換えられる時であって（ＴａｒｇｅｔヘッダはまだＳＩＰメッセージ内に存在しないものとする）、書き換えが要求の経路再指定(rerouting)に起因する時はいつでも、ここでは「Ｔａｒｇｅｔ」ヘッダと呼ばれる新しいヘッダがＳＩＰエンティティによってＳＩＰメッセージ内に挿入される。Ｔａｒｇｅｔヘッダが既にＳＩＰメッセージ内に存在し、宛先再指定の動作に起因してＲｅｑｕｅｓｔ−ＵＲＩが書き換えられる場合、Ｔａｒｇｅｔヘッダは新しい宛先で書き換えられる。Ｔａｒｇｅｔヘッダは、メッセージを生成するために使用された最初の宛先ＩＤを含む。更なる代替例では、Ｔａｒｇｅｔヘッダは宛先再指定の場合には除去される。]
[0029] 要求においてＴａｒｇｅｔヘッダを利用可能な場合、Ｒｅｑｕｅｓｔ−ＵＲＩは経路再指定又は変換の動作に起因して書き換えられ、Ｔａｒｇｅｔヘッダは変化しないままである。]
[0030] 本実施形態の全ての代替例に関して、Ｔａｒｇｅｔヘッダを含んだＳＩＰメッセージを受信する受信側エンティティは、Ｔａｒｇｅｔヘッダフィールドから現在の宛先を判断することができる。]
[0031] 更に、本実施形態の全ての代替例に関して、Ｔａｒｇｅｔヘッダを含まないＳＩＰメッセージを受信する受信側エンティティは、Ｒｅｑｕｅｓｔ−ＵＲＩから現在の宛先を判断することができる。]
[0032] 着信側ユーザのための登録／ホームプロキシとして機能するＳＩＰエンティティが登録されたＵＡのコンタクトアドレスでＲｅｑｕｅｓｔ−ＵＲＩを書き換える場合、ＳＩＰエンティティは更に、ＲＦＣ３４５５に記述されているように、Ｒｅｑｕｅｓｔ−ＵＲＩの以前の値を伴うＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールドを挿入する。]
[0033] なお、Ｔａｒｇｅｔヘッダフィールド及びＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールドは異なるセマンティクス(semantics)を持つ。宛先に対するセッションを開始するために使用された最初の宛先ＩＤをＴａｒｇｅｔヘッダフィールドが表す場合、Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールドは、最後に取られた経路が重要な情報を提示する場合のためにＲｅｑｕｅｓｔ−ＵＲＩの前にユーザに到達するために使用された最後のＡｏＲを表す。]
[0034] Ｈｉｓｔｏｒｙ−Ｉｎｆｏの用途の拡張
Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダ（ＲＦＣ４２４４）は、メッセージがルーティングされる過程でＲｅｑｕｅｓｔ ＵＲＩが持っていた値に関するブラインド・レコードである。その結果、このヘッダは現在の要求の宛先も含む。]
[0035] 上述した新しいＴａｒｇｅｔヘッダのソリューションに対する代替は、要求の現在の宛先を記録しているＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のエントリに対してマーキングすることにより、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダの用途を拡張することである。この拡張をサポートするＳＩＰエンティティをＳＩＰメッセージが通過し、宛先再指定の動作に起因してＳＩＰエンティティがＲｅｑｕｅｓｔ−ＵＲＩの値を書き換える際に、ＳＩＰエンティティは以前のＲｅｑｕｅｓｔ−ＵＲＩの値をＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダフィールドのエントリ内に追加し、加えて、そのエントリに対して宛先再指定エントリとしてタグ付けする。どのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダエントリが意図された宛先を指しているかを受信側エンティティが判断するために、受信側エンティティは宛先再指定の動作に起因するものとしてタグ付けされている最後のＨｉｓｔｏｒｙ−Ｉｎｆｏエントリを調べることができ、又は、タグ付けされたエントリが存在しない場合は最初のエントリを使用する。タグ付けされたエントリのシーケンスは、履歴におけるメタレベルとしての宛先の軌跡を提供する。]
[0036] 更なる代替では、要求の現在の宛先のみがマーキングされる。この拡張をサポートするＳＩＰエンティティをＳＩＰメッセージが通過し、宛先再指定の動作に起因してＳＩＰエンティティがＲｅｑｕｅｓｔ−ＵＲＩの値を書き換える際に、ＳＩＰエンティティは以前のＲｅｑｕｅｓｔ−ＵＲＩの値をＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダフィールドのエントリ内に追加し、加えて、そのエントリに対して宛先再指定エントリとしてタグ付けする。ＳＩＰエンティティは更に、そのようなタグを以前のＨｉｓｔｏｒｙ−Ｉｎｆｏ要素から除去する。どのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダエントリが意図された宛先を指しているかを受信側エンティティが判断するために、受信側エンティティは宛先再指定の動作に起因するものとしてタグ付けされている最後のＨｉｓｔｏｒｙ−Ｉｎｆｏエントリを調べることができ、又は、タグ付けされたエントリが存在しない場合は最初のエントリを取り入れる。]
[0037] 更なる代替のメカニズムでは、これは現行のＲＦＣ４２４４を実装するＳＩＰエレメントとは互換性が無いかもしれないが、宛先再指定のみがＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダに記録される。受信側エンティティが現在の宛先を判断するために、受信側エンティティは最後のＨｉｓｔｏｒｙ−Ｉｎｆｏエントリを調べる。]
[0038] 本実施形態の全ての代替例に関して、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダを含んでいないＳＩＰメッセージを受信する受信側エンティティは、現在の宛先をＲｅｑｕｅｓｔ−ＵＲＩから判断することができる。]
[0039] ＳＩＰエンティティが着信側ユーザのための登録／ホームプロキシとして機能する場合、ＳＩＰエンティティは登録されたＵＡのコンタクトアドレスでＲｅｑｕｅｓｔ−ＵＲＩを書き換え、加えて、ＲＦＣ３４５５に記述されているように、Ｒｅｑｕｅｓｔ−ＵＲＩの以前の値を伴うＰ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールドを挿入することができる。]
[0040] 上述した代替の諸実施形態は、図１のフロー図において要約可能である。以下の番号付けは図における番号付けに対応する。] 図１
[0041] １．ＳＩＰメッセージが、ＳＩＰプロキシノード（例えば、ＩＭＳネットワークのＣＳＣＦ）において受信される。]
[0042] ２．ノードがＳＩＰメッセージのＲｅｑｕｅｓｔ−ＵＲＩヘッダを書き換える。]
[0043] ３．Ｒｅｑｕｅｓｔ−ＵＲＩの書き換えが宛先再指定の動作に起因するものであるか否かを確認するためにノードがチェックを行う。そうであればステップ４に移行し、宛先再指定が経路再指定又は変換の動作に起因するものである場合は、ステップ６に移行する。]
[0044] ４．Ｔａｒｇｅｔヘッダの実施形態が使用される場合、ＳＩＰメッセージ内にＴａｒｇｅｔヘッダが既に存在するか否かを確認するためにチェックを行う。存在する場合はステップ５に移行し、存在しない場合はステップ８に移行する。Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダの実施形態が使用される場合、現在記録されている宛先がＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダにおいてタグ付けされているか否かを確認するためにノードがチェックを行う。タグ付けされている場合はステップ５に移行し、タグ付けされていない場合はステップ８に移行する。]
[0045] ５．Ｔａｒｇｅｔヘッダの実施形態が使用される場合、Ｔａｒｇｅｔヘッダが除去されるか又は新しい宛先で書き換えられ、ステップ８に移行する。Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダの実施形態が使用される場合、新しい現在の宛先を表す履歴エントリがタグ付けされる。加えて、以前にタグ付けされたエントリからタグが除去されてもよい。そして、ステップ８に移行する。]
[0046] ６．Ｔａｒｇｅｔヘッダの実施形態が使用される場合、ＳＩＰメッセージ内にＴａｒｇｅｔヘッダが既に存在するか否かを確認するためにチェックを行う。存在する場合はステップ８に移行し、存在しない場合はステップ７に移行する。Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダの実施形態が使用される場合、現在記録されている宛先がＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダにおいてタグ付けされているか否かを確認するためにノードがチェックを行う。タグ付けされている場合はステップ８に移行し、タグ付けされていない場合はステップ７に移行する。]
[0047] ７．Ｔａｒｇｅｔヘッダの実施形態が使用される場合、宛先再指定の動作の前に、Ｒｅｑｕｅｓｔ ＵＲＩの値を伴うＴａｒｇｅｔヘッダがＳＩＰメッセージに挿入される。Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダの実施形態が使用される場合、それ以上の動作は必要とされない。]
[0048] ８．ＳＩＰメッセージが通信ネットワーク内の更なるノードへ送信される。]
[0049] 図２を参照して、例としてのシグナリング図を示す。Ｔａｒｇｅｔヘッダの実施形態が使用される場合、ＵＥＡか経路再指定中間者１へのメッセージ１は、Ｒｅｑｕｅｓｔ ＵＲＩ内に宛先１を含んだＳＩＰＩＮＶＩＴＥメッセージである。以下は、シグナリングシーケンスにおける各メッセージに関する経路及び宛先に対応する。
m1 INVITE
target1
m2 INVITE route1
Target: target1
m3 INVITE route2
Target: target1
m4 INVITE target2
m5 INVITE route3
Target: target2] 図２
[0050] Ｔａｒｇｅｔヘッダの別の実施形態では、図２に示すシグナリングシーケンスは以下の通りである。
m1 INVITE
target1
m2 INVITE route1
Target: target1
m3 INVITE route2
Target: target1
m4 INVITE target2
Target: target2
m5 INVITE route3
Target: target2] 図２
[0051] Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダが使用される場合、図２に従う例としてのシグナリングシーケンスは以下の通りである。
m1 INVITE
target1
m2 INVITE route1
History-Info:
＜target1＞;index=1;targetentry,
＜route1＞;index=1.1
m3 INVITE route2
History-Info:
＜target1＞;index=1;targetentry,
＜route1＞;index=1.1
＜route2＞;index=1.1.1
m4 INVITE target2
History-Info:
＜target1＞;index=1;targetentry,
＜route1＞;index=1.1
＜route2＞;index=1.1.1
＜target2＞;index=1.1.1.1;targetentry
m5 INVITE route3
History-Info:
＜target1＞;index=1;targetentry,
＜route1＞;index=1.1
＜route2＞;index=1.1.1
＜target2＞;index=1.1.1.1;targetentry
＜route3＞;index=1.1.1.1.1] 図２
[0052] Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダの別の実施形態では、図２に従う例としてのシグナリングシーケンスは以下の通りである。
m1 INVITE
target1
m2 INVITE route1
History-Info:
＜target1＞;index=1;targetentry,
＜route1＞;index=1.1
m3 INVITE route2
History-Info:
＜target1＞;index=1;targetentry,
＜route1＞;index=1.1
＜route2＞;index=1.1.1
m4 INVITE target2
History-Info:
＜target1＞;index=1; ［宛先エントリタグが除去されたことに注目］
＜route1＞;index=1.1
＜route2＞;index=1.1.1
＜target2＞;index=1.1.1.1;targetentry
m5 INVITE route3
History-Info:
＜target1＞;index=1;
＜route1＞;index=1.1
＜route2＞;index=1.1.1
＜target2＞;index=1.1.1.1;targetentry
＜route3＞;index=1.1.1.1.1] 図２
[0053] 図３を参照すると、通信ネットワークにおいて使用されるノードが概略的に示されている。ノード６は例えば、ＣＳＣＦのようなＩＭＳネットワーク内のＳＩＰプロキシノードであり得る。ノード６は、ＳＩＰメッセージを受信する受信機７、及び、ＳＩＰメッセージ内のＲｅｑｕｅｓｔ−ＵＲＩヘッダを書き換え情報（上述したような、新しいＴａｒｇｅｔヘッダ又はＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のタグ付けエントリ）を追加するプロセッサ９を有する。ノードは更に、ＳＩＰメッセージを更なるノードへ送信する送信機８を備える。] 図３
[0054] 図４を参照すると、ＵＥのような着信側ノードが概略的に示されている。着信側ノード１０は、ＳＩＰメッセージを受信する受信機１１、及び、受信したＳＩＰメッセージに含まれるＲｅｑｕｅｓｔ−ＵＲＩヘッダの内容が元々送信されたメッセージのＲｅｑｕｅｓｔ−ＵＲＩの内容と異なるか否かを判定するプロセッサ１２を備える。このようにして、着信側ノードは元の宛先アドレスを判断し、ユーザやユーザに対するサービスに代理してポリシーを実行するためにこれを使用することができる。] 図４
[0055] 例
以下は、上述した新しいＴａｒｇｅｔヘッダをどのように使用可能かに関する例である。しかしながら、拡張されたＨｉｓｔｏｒｙ−Ｉｎｆｏの用途は、以下の例において同様のやり方で使用可能である。]
[0056] １．未知のエイリアス
単一のＵＡは、例えばエイリアスとして使用するために、自分に関連付けられた複数のＡｏＲを持つことができる。呼の宛先がどのエイリアスであるかを知ることは、呼の受信者にとって望ましいであろう。Ｐ−Ｃａｌｌｅｄ−Ｐａｒｔｙ−ＩＤヘッダフィールド（ＲＦＣ３４５５）は、未知のエイリアスのシナリオに対処するために導入されており、新しいＴａｒｇｅｔヘッダフィールドもこの問題に対処するであろう。]
[0057] ２．未知のグローバルにルーティング可能なユーザエージェントＵＲＩ（ＧＲＵＵ）
ＧＲＵＵはＵＡに割り当てられるＵＲＩであり、ＡｏＲと同じ性質を多数持つが、その特定のインスタンスに対してのみ要求がルーティングされるようにする。いくつかの状況においては、ＧＲＵＵ又はＡｏＲのいずれを使用して呼が宛先指定されたかを知ることは、呼の受信者にとって望ましいかもしれない。これは「未知のエイリアス」の問題の変形であり、ＲＦＣ３４５５によって対処される。新しいＴａｒｇｅｔヘッダフィールドも、最初の宛先として使用されるＧＲＵＵに関するこの問題を解決する。]
[0058] ３．限定使用アドレス
限定使用アドレスは、要求に応じて生成されＵＡに提供されるＳＩＰＵＲＩである。着呼は、そのＵＲＩに宛てられた通信をＵＡが望む間のみ、受け付けられる。限定使用アドレスは特に、音声スパムに対抗するために使用される。これは「未知のエイリアス」の問題の別の変形であり、ＲＦＣ３４５５によって対処される。新しいＴａｒｇｅｔヘッダフィールドも、この問題を解決する。]
[0059] ４．サブ・アドレッシング
サブアドレスはサブドメイン内のアドレスであり、ペアレントドメインの単一のアドレスの中に他のサブアドレスと共に多重化されるものである。これは例えば、小さな企業の従業員、又は、自分たちにコンタクト可能な別々のサブアドレスを持ちたいと願う家族グループによって使用される。Ｒｅｑｕｅｓｔ−ＵＲＩはホームプロキシにおいて書き換えられるという事実に起因して、サブアドレスを搬送するために使用されるＳＩＰＵＲＩパラメータはホームプロキシにおいて失われるであろうから、現行ではＳＩＰを使用するとサブ・アドレッシングの特徴は利用できない。この問題は、新しいＴａｒｇｅｔヘッダフィールドを使用して克服される。]
[0060] ５．サービスの起動
ＵＲＩは、加入者ではなくネットワーク内のサービスを宛先指定するために使用可能である。ＵＲＩは、サービスの振る舞いを制御するパラメータを含むことができる。しかしながら、サービスを指し示すようにプロキシがＲｅｑｕｅｓｔ−ＵＲＩを書き換えた場合、シグナルパスにおける更なるプロキシによってＲｅｑｕｅｓｔ−ＵＲＩが書き換えられないであろうという保証は無い。新しいＴａｒｇｅｔヘッダフィールドは、全てのサービス起動情報を含んだ元の複合ＵＲＩを保持するであろうから、このシナリオを解決する。]
[0061] ６．緊急サービス
緊急呼をサポートするシステムの主な要件は、ＳＩＰＩＮＶＩＴＥが緊急呼に関するものであるということをネットワークが知ってＳＩＰシグナリングに優先性を与えることを確実にするために、緊急呼のためのＳＩＰＩＮＶＩＴＥ要求が何らかのやり方で「マーキング」されることである。攻撃者による悪用を回避するために、マーキングは要求の宛先アドレス自体に適用される。このメカニズムは、呼を処理するであろうプロキシ又はＵＡに対して呼を向けるために途中のプロキシのいずれかがＲｅｑｕｅｓｔ−ＵＲＩを書き換えようとする場合、機能しないであろう。しかしながら、新しいＴａｒｇｅｔヘッダフィールドは、緊急ＵＲＮを保持するであろうから、このシナリオを解決する。]
[0062] ７．フリーダイヤル番号
フリーダイヤル番号は、ユーザが課金されずに番号に発呼することを可能にする。シグナリングパスの中間ノードがＲｅｑｕｅｓｔ−ＵＲＩを書き換える場合、課金機能は、その呼に対してはユーザに課金してはならないということを認識できない。新しいＴａｒｇｅｔヘッダフィールドは、フリーダイヤル番号を保持するので、このシナリオを解決するであろう。]
[0063] この明細書の範囲を超えるが、注目すべきこととして、本発明は、ＵＡにコンタクトするために使用される宛先アドレス（これは以前は隠されていた）をＵＡに対して明らかにする。この情報をＵＡに対して明らかにすることは望ましくない状況もあるかもしれない。この場合、ホームプロキシは、宛先アドレスを含んだヘッダ（又は他の表示情報）を除去すべきである。]
[0064] 本発明によれば、どの宛先ＩＤの下で要求が転送されたかを企業ネットワーク及び受信側ＵＥが知ることができる。保持される必要があるのは、Ｒｅｑｕｅｓｔ ＵＲＩの書き換えの履歴ではなく、関係する宛先ＩＤのみである。このことは、帯域利用及び処理の効率性を改善する。更に、本発明は既存のルーティングメカニズムと干渉せず、ルーズルーティングをサポートしないホームプロキシと共存可能である。このメカニズムを使用するエンティティにとって、次のホップがこのメカニズムをサポートするか否かに関する知識を持つ必要は無く、着信側ＵＡにとって、自分がこのメカニズムをサポートするか否かを自分のホームプロキシに知らせる必要は無い。本発明は、端末がルーズルーティングをサポートすることを要求しないので、後方互換性を有する。ＳＩＰのルーティングメカニズム自体は変更されないので、通過されるプロキシのうちの１つがこのメカニズムを理解しないシナリオにおいて、ルーティングは依然として成功する。起こり得る最悪のことであっても、着信側ＵＡに到達するために使用された意図された宛先ＩＤに関して着信側ＵＡが不正確な情報を受信するかもしれないということである。Ｔａｒｇｅｔヘッダは、転送パーティーが自分のＩＤを明らかにすることを望まない場合に、転送パーティーを特定する情報を搬送するかもしれない。]
[0065] 本発明は、ＲＦＣ３３９８、３ＧＰＰ ＴＳ２９．１６３、及びＩＴＵ−Ｔ勧告Ｑ．１９１２．５に記述される相互作用の手順に従ってＰＳＴＮネットワークに対するマッピング及びルーティングのためにＲｅｑｕｅｓｔ−ＵＲＩの値を使用するＭＧＣＦと、十分に後方互換性を有する。]
[0066] 当業者に理解されるであろうこととして、本発明の範囲から逸脱すること無しに、上述の実施形態に対して多様な修正をなすことができる。例えば、上で提供した例の多くはＩＭＳを例としてのネットワークとして使用するが、理解されるであろうこととして、本発明はＳＩＰシグナリングを使用する任意の通信ネットワークに対して適用される。]

权利要求:

請求項1
通信ネットワークにおいてセッション開始プロトコル・メッセージを処理する方法であって、前記ネットワーク内のノードにおいて、Ｒｅｑｕｅｓｔ−ＵＲＩヘッダを有するセッション開始プロトコル・メッセージを受信するステップと、前記セッション開始プロトコル・メッセージ内の前記Ｒｅｑｕｅｓｔ−ＵＲＩヘッダを書き換えるステップと、前記メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な情報を前記セッション開始プロトコル・メッセージに追加するステップと、前記セッション開始プロトコル・メッセージを更なるノードへ送信するステップと、を備えることを特徴とする方法。
請求項2
前記メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な前記情報は、前記現在の宛先のＩＤを含む新しいメッセージヘッダを含むことを特徴とする請求項１に記載の方法。
請求項3
前記メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な前記情報は、前記メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のエントリに関連付けられるタグを含み、当該タグは、前記エントリが宛先再指定の動作から生じたものであるということを示すことを特徴とする請求項１に記載の方法。
請求項4
前記Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内に入れられた以前の宛先アドレスに関連付けられた既存のタグを除去するステップと、前記Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内に入れられた現在の宛先アドレスにタグを関連付けるステップと、を更に備えることを特徴とする請求項３に記載の方法。
請求項5
通信ノードにおいて使用するための中間ノードであって、セッション開始プロトコル・メッセージを受信する受信機と、前記セッション開始プロトコル・メッセージ内のＲｅｑｕｅｓｔ−ＵＲＩヘッダを書き換え、前記メッセージの現在の宛先アドレスを判断するためにリモートノードが使用可能な情報を前記セッション開始プロトコル・メッセージに追加する、プロセッサと、前記セッション開始プロトコル・メッセージを更なるノードへ送信する送信機と、を備えることを特徴とする中間ノード。
請求項6
前記プロセッサは、前記現在の宛先のＩＤを含む新しいメッセージヘッダを前記セッション開始プロトコル・メッセージに挿入するように構成されることを特徴とする請求項５に記載の中間ノード。
請求項7
前記プロセッサは、前記メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のアドレスエントリにタグを追加するように構成され、当該タグは、前記エントリが宛先再指定の動作から生じたものであるということを示すことを特徴とする請求項５に記載の中間ノード。
請求項8
前記プロセッサは、前記メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のアドレスエントリにタグを追加するように構成され、当該タグは、前記エントリが前記メッセージの宛先アドレスを含むということを示すことを特徴とする請求項５に記載の中間ノード。
請求項9
通信ノードにおいて使用するためのノードであって、セッション開始プロトコル・メッセージを受信する受信機と、前記ノードと発信元ノードとの間の中間ノードによって前記メッセージに追加された情報に基づいて、前記メッセージの現在の宛先アドレスを判断するプロセッサと、を備えることを特徴とするノード。
請求項10
前記プロセッサは、前記メッセージを前記ノードへ送信する前に前記中間ノードによって前記メッセージ内に挿入されたＴａｒｇｅｔヘッダの内容を判断することにより、前記メッセージの前記現在の宛先アドレスを判断するように構成されることを特徴とする請求項９に記載のノード。
請求項11
前記プロセッサは、前記メッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダ内のタグ付けされたエントリを分析することにより、前記メッセージの前記現在の宛先アドレスを判断するように構成されることを特徴とする請求項９に記載のノード。